home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 736 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.4 KB
  1. From: Torsten Scherer <itschere@techfak.uni-bielefeld.de>
  2. Subject: strange Fselect/Finstat behaviour...
  3. Date: Mon, 3 Jan 94 0:29:54 +0100
  4.  
  5.  Hope anyone out there has had a good start into the new year...
  6.  
  7.  Mine was a bit nervous, because while I was trying to get my head back
  8. into a more comfortable state after the New Years Eve party it was once
  9. again hit by a severe programming problem. Obviously it wasn't the perfect
  10. time for this problem to arise, so I didn't really manage to track it down.
  11.  
  12.  I was trying to improve my `talk' program, which puts the current device
  13. into RAW mode to be able to read keys like ^C for example, which then get
  14. sent through a pipe to inform the remote partner that a connection is to
  15. be shut down.
  16.  
  17.  Knowing that Fselect() only really works on pipes or the `real' console
  18. device, but not on other devices, I used Fselect(50, &rfd, 0L, 0L) to not
  19. spend too much time in a busy-poll loop and still be able to use it for
  20. tty input. Since the corresponding tty is in RAW mode, I'd expect it to
  21. give me a 0x03 from Fread() when ^C is pressed. Instead, the process got
  22. the SIGINT signal and was killed all the time.
  23.  
  24.  When trying not to use Fselect() at all for tty input, but just for pipe
  25. input with a timeout, and later manually check the tty with Finstat() I got
  26. the same result. Since a RAW Fread() will return for every char regardless
  27. how many you ordered, but not if there isn't one at all, I ran out of clues
  28. on how to check the tty input without blocking and changed my program to
  29. catch SIGINT instead of reading it from the tty so it now more or less
  30. does what I want.
  31.  
  32.  But the problem remains and if you'd like to check it, then run:
  33.  
  34. /*
  35.  *    murphy on the road again...
  36.  */
  37.  
  38. #include <ioctl.h>
  39. #include <mintbind.h>
  40. #include <signal.h>
  41. #include <stdio.h>
  42.  
  43. void catch(long sig)
  44. {
  45.     printf("hit by SIGINT\r\n");
  46. }
  47.  
  48. void main()
  49. {
  50.     struct sgttyb    tty;
  51.     long        rfd;
  52.     char        c;
  53.  
  54.     Psignal(SIGINT, catch);
  55.  
  56.     ioctl(0, TIOCGETP, &tty);
  57.     tty.sg_flags = RAW;
  58.     ioctl(0, TIOCSETP, &tty);
  59.  
  60.     for (;;) {
  61. #if 1
  62.         if (Finstat(0)) {
  63. #else
  64.         rfd = 1;
  65.         (void)Fselect(50, &rfd, 0L, 0L);
  66.         if (rfd) {
  67. #endif
  68.             Fread(0, 1L, &c);
  69.             printf("key = %i\r\n", c);
  70.         }
  71.     }
  72. }
  73.  
  74.  If you do so, you'll have to face the strange fact that the _first_ ^C will
  75. raise the signal, whereas every following one will read as 0x03 from the
  76. Fread() call.
  77.  
  78.  A pure:
  79.  
  80. for (;;) {
  81.     Fread(0, 1L, &c);
  82.     printf("key = %i\r\n", c);
  83. }
  84.  
  85.  won't do this but report 0x03 for every ^C instead, just like you and I
  86. might have expected it, but gives you no possibility to do other things
  87. if there isn't any input at all.
  88.  
  89.  All this happenes with MiNT 1.09 plus no patches except the nalloc stuff
  90. and my own ones dealing with the biosfs and the sticky bit AND the original
  91. MiNT 1.04. Allthough I may have very well missed some patches cause I don't
  92. save them all if I think I don't need them, but prefer to wait for the next
  93. official update instead, I consider this being a `new' problem.
  94.  
  95.  So has anyone got the faintest idea what this is meant to say me? Looks
  96. like the combination of dev->ioctl(FIONREAD) and/or dev->select affects the
  97. process' signal stuff in a very bad way, but before I try to get through
  98. this I'd like to have it discussed here.
  99.  
  100. so long,
  101. TeSche
  102. --
  103. PS: If the above written looks weird, then that's probably because it _is_.
  104. WhoDunnIt: Torsten Scherer (Schiller, Tesche, ...)
  105. Where: Faculty of Technology, University of Bielefeld, Germany
  106. EMail: itschere@techfak.uni-bielefeld.de / tesche@hrz.uni-bielefeld.de
  107.